In general, distributed networks contain at least one server and multiple remote clients that access one or more resources (e.g., data files) on the server. Locking facilities are typically provided in such distributed networks to control the use of the resources by the multiple clients. By acquiring a lock on a record, or a file, or other resource (typically located on a server), a client indicates its intention to make use of the record, file or other resource. In practice there are various kinds of locks, including locks for enforcing exclusive access, locks for enforcing shared access, locks on portions of a data file, and locks on an entire data file.
Typically, such distributed networks contain a global locking service for distributing locks to each of the multiple clients requiring access to the resources. For example, each time a client requires accessing a resource on the server, the client requests and obtains a lock from the global locking service. The lock is used to protect access to the resource on the server, i.e., only those clients that hold a valid lock are allowed to access to the resource. The client then transmits the lock to the server together with a request to access the resource, and the server determines if it should grant access to the resource. Typically, the server queries the global locking service to determine whether the lock is valid. If the lock is valid the client is allowed access to the resource. If the lock is not valid the request to access the resource is rejected.
The above-described method requires constant communication between the server and the global locking service. However, this constant communication is inefficient, as it consumes bandwidth and places an unnecessary high load on the global locking server. In addition, extra programming care is required to allow the server to continue responding to client requests even when the global locking service becomes unavailable. Examples of requests the server may respond to are requests for resources not protected by locks, and requests for resources that are protected by locks managed by a different global locking service (i.e., there may be multiple, independent global locking services, and different resources may be protected by locks managed by different locking services).
Another existing system for controlling locks requires synchronization between the clocks on the clients, server, and global locking service. If the clocks are synchronized, then leases that expire after a set time can be used by the system. For example, when the client obtains a lock, it also receives a lease. The lease includes an expiration time, which declares that the client holds the lock until at least the expiration time. The client transmits the lease to the server along with its request to access the file. The server checks its clock, and accepts the request to access the file if the lease has not yet expired. However, this method either requires 1) communication between the server and the global locking service to synchronize times, or 2) communication between the sever and a remote clock, and communication between the global locking service and the remote clock. Again such constant communication is inefficient. Moreover, this method is also subject to clock skew caused by propagation delays or the like.
To reduce communication between the server and the lock service, some systems store state information about lock distribution and validation. The server consults this state rather than contacting the locking service. To avoid requiring the server to contact the locking service upon restart, this state must be made persistent. However, maintaining a persistent state requires non-volatile memory, and also requires procedures for re-establishing the state of the system when recovering from a crash or power failure or the like, which adds expense to the system.
In light of the above, it would be highly desirable to provide a system and method for enforcing a locking regime at a server without requiring a local persistent state and without requiring direct constant communication between the server and a global locking service.